<!DOCTYPE html>
<html>

<head>
    
    <meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="chrome=1">
<meta name="HandheldFriendly" content="True">
<meta name="MobileOptimized" content="320">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="referrer" content="no-referrer">

<meta name="description" content="A new Hugo site.">
<title>
    MongoDB大发现 - dashjay
</title>



<link rel="shortcut icon" href="/sam.ico">








<link rel="stylesheet" href="/css/main.min.4321edce0de245f4b1d32680d89ac669940fe5dec17e1791c721d9a0954987b4.css" integrity="sha256-QyHtzg3iRfSx0yaA2JrGaZQP5d7BfheRxyHZoJVJh7Q=" crossorigin="anonymous" media="screen">





<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Didact+Gothic">

<meta name="twitter:card" content="summary_large_image"/>
<meta name="twitter:image" content="http://dashjay.gitee.io/tn.png"/>

<meta name="twitter:title" content="MongoDB大发现"/>
<meta name="twitter:description" content="为什么博客里突然冲出来一个周报呢，别问，问就是不知道。
这周干了啥：
nodebb MongoDB数据库 看了nodebb对应的MongoDB的后台数据库结构。发现他分为三个库。
 session object &amp;&amp;&amp;忘了  其中所有静态内容都存在object这个库中。
 我发现他有个特点，这个特点有点像css，我在这里尝试描述一下，看是否描述的清楚。
 曾经我以为MongoDB这样用性能很好，因为可以储存非固定结构的内容，我之前的结构是这样的
{ 问题信息:blabalba, 回答:[ {回答信息：blablabal,评论:[{评论信息....}]}, ] } 我始终以为MongoDB就是这么用的，知道我看了nodebb。他尝试以最小单元来储存，这才让我突然意识到，经常更改的时候回容易发生信息不一致。他是这么存的
// 问题 { qid:1, 问题信息:blablabal } // 回答 { aid:1, to_qid:1, 答案信息:blabalbal } // 评论 { cid:1, to_aid:1 to_qid:1 评论内容:blabalbal } 他这样存的时候修改的时候只需要修改单元即可，这种叠层式的储存还体现在下方特点。
{ key:&quot;qid:1:like_byuid&quot;, member:[ 1,2,3,4 ] } 他这样储存乍一看有很多问题，比如当点赞人数非常多的话，每次添加一个点赞非常困难。但是相对于每个点赞存一条，我觉得这个方法还是可以的。
那么一条记录，将记录分为若干个[永远不变的固定部分，偶尔改变的部分，经常改变的部分]然后分开存，学到了，搭配Redis可以最好的发挥MongoDB的最大优势。
在微信小程序处理小而复杂的下拉刷新和多tab 微信小程序本身支持下拉刷新，但是有点鸡肋，会出各种问题，因为横向会改变tab，纵向会下拉刷新，还是有点麻烦，描述清楚也有点麻烦，因此我之后再补充。
开发计划  教室系统的后台强力开发 小程序的信息发布系统整合  "/>

<meta property="og:title" content="MongoDB大发现" />
<meta property="og:description" content="为什么博客里突然冲出来一个周报呢，别问，问就是不知道。
这周干了啥：
nodebb MongoDB数据库 看了nodebb对应的MongoDB的后台数据库结构。发现他分为三个库。
 session object &amp;&amp;&amp;忘了  其中所有静态内容都存在object这个库中。
 我发现他有个特点，这个特点有点像css，我在这里尝试描述一下，看是否描述的清楚。
 曾经我以为MongoDB这样用性能很好，因为可以储存非固定结构的内容，我之前的结构是这样的
{ 问题信息:blabalba, 回答:[ {回答信息：blablabal,评论:[{评论信息....}]}, ] } 我始终以为MongoDB就是这么用的，知道我看了nodebb。他尝试以最小单元来储存，这才让我突然意识到，经常更改的时候回容易发生信息不一致。他是这么存的
// 问题 { qid:1, 问题信息:blablabal } // 回答 { aid:1, to_qid:1, 答案信息:blabalbal } // 评论 { cid:1, to_aid:1 to_qid:1 评论内容:blabalbal } 他这样存的时候修改的时候只需要修改单元即可，这种叠层式的储存还体现在下方特点。
{ key:&quot;qid:1:like_byuid&quot;, member:[ 1,2,3,4 ] } 他这样储存乍一看有很多问题，比如当点赞人数非常多的话，每次添加一个点赞非常困难。但是相对于每个点赞存一条，我觉得这个方法还是可以的。
那么一条记录，将记录分为若干个[永远不变的固定部分，偶尔改变的部分，经常改变的部分]然后分开存，学到了，搭配Redis可以最好的发挥MongoDB的最大优势。
在微信小程序处理小而复杂的下拉刷新和多tab 微信小程序本身支持下拉刷新，但是有点鸡肋，会出各种问题，因为横向会改变tab，纵向会下拉刷新，还是有点麻烦，描述清楚也有点麻烦，因此我之后再补充。
开发计划  教室系统的后台强力开发 小程序的信息发布系统整合  " />
<meta property="og:type" content="article" />
<meta property="og:url" content="http://dashjay.gitee.io/posts/2019-12-19/" />
<meta property="og:image" content="http://dashjay.gitee.io/tn.png"/>
<meta property="article:published_time" content="2019-12-19T00:00:00+00:00" />
<meta property="article:modified_time" content="2019-12-19T00:00:00+00:00" /><meta property="og:site_name" content="Call me Sam" />


    

    
    
    
    <title>
        
        MongoDB大发现
        
    </title>
</head>

<body>
    
    
    <header class="wrap flex-container">
        <h1>MongoDB大发现</h1>
    </header>
    
    <main class="wrap">
        
<div class="flex-container">
    <aside role="complementary">
        Thu Dec 19, 2019 &#183; 53 words
        <div class="tag-container">
            
        </div>
    </aside>
    <hr />
    <article role="article">
        <p>为什么博客里突然冲出来一个周报呢，别问，问就是不知道。</p>
<p>这周干了啥：</p>
<h1 id="nodebb-mongodb数据库">nodebb MongoDB数据库</h1>
<p>看了nodebb对应的MongoDB的后台数据库结构。发现他分为三个库。</p>
<ul>
<li>session</li>
<li>object</li>
<li>&amp;&amp;&amp;忘了</li>
</ul>
<p>其中所有静态内容都存在object这个库中。</p>
<blockquote>
<p>我发现他有个特点，这个特点有点像css，我在这里尝试描述一下，看是否描述的清楚。</p>
</blockquote>
<p>曾经我以为MongoDB这样用性能很好，因为可以储存非固定结构的内容，我之前的结构是这样的</p>
<pre><code>{
问题信息:blabalba,
回答:[
    {回答信息：blablabal,评论:[{评论信息....}]},
  ]
}
</code></pre><p>我始终以为MongoDB就是这么用的，知道我看了nodebb。他尝试以最小单元来储存，这才让我突然意识到，经常更改的时候回容易发生信息不一致。他是这么存的</p>
<pre><code>// 问题
{
qid:1,
问题信息:blablabal
}
// 回答
{
aid:1,
to_qid:1,
答案信息:blabalbal
}
// 评论
{
cid:1,
to_aid:1
to_qid:1
评论内容:blabalbal
}
</code></pre><p>他这样存的时候修改的时候只需要修改单元即可，这种叠层式的储存还体现在下方特点。</p>
<pre><code>{
key:&quot;qid:1:like_byuid&quot;,
member:[
1,2,3,4
  ]
}
</code></pre><p>他这样储存乍一看有很多问题，比如当点赞人数非常多的话，每次添加一个点赞非常困难。但是相对于每个点赞存一条，我觉得这个方法还是可以的。</p>
<p>那么一条记录，将记录分为若干个[<strong>永远不变的固定部分</strong>，<strong>偶尔改变的部分</strong>，<strong>经常改变的部分</strong>]然后分开存，学到了，搭配Redis可以最好的发挥MongoDB的最大优势。</p>
<h1 id="在微信小程序处理小而复杂的下拉刷新和多tab">在微信小程序处理小而复杂的下拉刷新和多tab</h1>
<p>微信小程序本身支持下拉刷新，但是有点鸡肋，会出各种问题，因为横向会改变tab，纵向会下拉刷新，还是有点麻烦，描述清楚也有点麻烦，因此我之后再补充。</p>
<h1 id="开发计划">开发计划</h1>
<ul>
<li>教室系统的后台强力开发</li>
<li>小程序的信息发布系统整合</li>
</ul>

    </article>
</div>


        
<nav role="navigation" class="flex-container bottom-menu">
    
<hr />
<p>


    
        <a href="/posts">back</a>
        
            &#183;
        
    

    
        
            <a href="/posts">我的文章</a>
        
    
    
        
            &#183; 
            <a href="/gallery">画册</a>
        
            &#183; 
            <a href="/portfolio">珍贵时光</a>
        
            &#183; 
            <a href="/about">关于我</a>
        
    
    &#183; 
    <a href="/">
        main
    </a>

</p>
</nav>

    </main>
    
    <footer class="flex-container footer">I will code for a long time. Would you?</footer>
    
    
</body>

</html>